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ABSTRACT 

The  Family  of  Integrated  Rapid  Response  Equipment  (FIRRE)  is  an  advanced  technology  demonstration  program 
intended  to  develop  a  family  of  affordable,  scalable,  modular,  and  logistically  supportable  unmanned  systems  to  meet 
urgent  operational  force-protection  needs  and  requirements  worldwide.  The  near-term  goal  is  to  provide  the  best 
available  unmanned  ground  systems  to  the  warfighter  in  Iraq  and  Afghanistan.  The  overarching  long-term  goal  is  to 
develop  a  fully-integrated,  layered  force-protection  system  of  systems  for  our  forward  deployed  forces  that  is  networked 
with  the  future  force  C4ISR  systems  architecture.  The  intent  of  the  FIRRE  program  is  to  reduce  manpower  requirements, 
enhance  force-protection  capabilities,  and  reduce  casualties  through  the  use  of  unmanned  systems.  FIRRE  is  sponsored 
by  the  Office  of  the  Under  Secretary  of  Defense,  Acquisitions,  Technology  and  Logistics  (OUSD  AT&L),  and  is 
managed  by  the  Product  Manager,  Force  Protection  Systems  (PM-FPS),  Fort  Belvior,  VA. 

The  command-and-control  element  of  FIRRE  is  the  Joint  Battlespace  Command  and  Control  System  (JBC2S)  for 
manned  and  unmanned  assets,  which  is  based  upon  the  Mobile  Detection  Assessment  Response  System  (MDARS) 
Multiple  Resource  Host  Architecture  (MRHA),  modified  to  operate  as  a  single  application  program  using  standard  DoD 
mapping  and  data  distribution  services.  JBC2S  is  an  evolution  of  the  MRHA  that  leverages  over  10  years  of 
development  in  unmanned  systems  command-and-control.  It  implements  the  functionality  of  the  MRHA  under  the 
dynamically  configurable  and  highly  modular  architecture  of  the  Multi-Robot  Operator  Control  Unit  (MOCU).  JBC2S 
is  a  network-centric,  geospatial  command  and  control  system  that  allows  the  field  commander  and  above  to  plan  and 
execute  missions  utilizing  multiple  and  disparate  manned  and  unmanned  assets.  It  utilizes  standard  map  formats 
(GeoTIFF,  DNC,  CADRG)  for  displaying  map  data  and  for  tracking  asset  placement  and  movement. 

Keywords:  FIRRE,  JBC2S,  MOCU,  MRHA,  command  and  control,  ground  surveillance  radar,  unattended 
ground  sensor,  unmanned  ground  vehicle,  robotic  architecture,  force  protection 

1.  BACKGROUND 

The  purpose  of  FIRRE  is  to  provide  the  best  available  force  protection  technologies  to  our  forward  deployed  forces 
today,  while  assisting  the  Combat  Developer  in  developing  concepts  and  capabilities  analysis  for  the  future.  FIRRE 
provides  our  soldiers,  airmen,  marines  and  sailors  with  an  enhanced  layered  force-protection  system  of  systems 
capability  that  provides  the  means  to  detect,  assess,  identify  and  respond  to  enemy  intrusion  activities.  FIRRE  enhances 
force  protection,  keeps  friendly  forces  out  of  harm’s  way  and  allows  commanders  to  return  warfighers  to  their  primary 
wartime  missions. 

The  proponent  for  FIRRE  is  the  U.S.  Army  Maneuver  Support  Center  (MANSCEN)  at  Fort  Leonard  Wood,  Missouri. 
Current  plans  call  for  FIRRE  to  participate  in  a  July- August  2006  demonstration  at  Yuma  Proving  Ground,  Arizona,  and 
to  eventually  integrate  with  the  Counter-Rocket,  Artillery  and  Mortar  (C-RAM)  program  as  part  of  MANSCEN’s  360- 
degree  Comprehensive  Fixed  Site  Protection  Initiative  (CFPI)  concept.  If  successful,  this  integrated  effort  will  be 
deployed  in  FY-07  to  provide  a  force-protection  capability  against  indirect  fire  and  ground  intruders. 
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The  formal  requirements  for  the  FIRRE  program  are  being  developed  by  MANSCEN  as  part  of  the  U.S.  Army  Training 
and  Doctrine  Command’s  (TRADOC)  chartered  Unit  Protection  Concept  Capability  Plan  (UPCCP)  Integrated  Concept 
Development  Team  (ICDT).  The  FIRRE  Integrated  Product  Team  (IPT)  was  charted  by  the  OSD  Joint  Robotics 
Program  ( JRP)  Coordinator  and  meets  periodically  as  required.  The  IPT  consists  of  over  60  members  from  1 0  different 
agencies.  Key  members  include  PM-FPS,  SSC  San  Diego,  MANSCEN,  Aberdeen  Test  Center,  PM  Robotic  and 
Unmanned  Sensors,  PM  Night  Vision,  and  other  members  of  OSD’s  JRP. 

Over  a  9  month  period,  the  FIRRE  IPT  developed  an  “80-percent  solution”  that  is  affordable,  supportable,  and  uses 
military  equipment  where  possible,  or  readily  available  commercial  equipment  where  practical.  The  resulting  system  has 
been  demonstrated  in  two  week-long  field  exercises  at  Hawthorne  Army  Depot  in  Nevada  over  an  operational  area  in 
excess  of  35  square  kilometers.  Portions  of  the  FIRRE  system  have  undergone  formal  environmental  testing  to  include 
heat  (to  120°  F),  blowing  rain  (to  40  MPH),  shock  and  vibration,  transportability,  and  center  of  gravity. 

2.  SYSTEM  OVERVIEW 

FIRRE  has  been  designed  to  be  deployed  in  a  rapid  fashion  for  tactical  missions  or  integrated  into  base  operations  as  part 
of  a  complete  force-protection  package.  As  FIRRE  is  a  system  of  systems,  its  configuration  is  flexible  and  scalable,  and 
the  exact  table  of  equipment  for  a  particular  application  is  based  upon  METT-T  (Mission,  Enemy,  Troops,  Terrain,  and 
Time).  Nominal  deployment  of  FIRRE  consists  of  a  single  command-and-control  (C2)  Station  controlling  multiple 
unmanned  assets  operating  over  an  area  of  approximately  1 00  square  kilometers,  which  approaches  the  physical  extents 
of  the  current  communications  architecture.  Shown  in  Figure  1,  a  conceptual  FIRRE  system  for  performing  perimeter 
security  of  a  moderate-sized  (7x5  kilometer)  ammunition  base  could  consist  of: 

•  1  Ml  152  HMMWV  with  S-788  Shelter 

•  6  Blue  Sky  Masts  with  Radio  Antennas 

•  1  PU-798  10KW  Generator  Trailer 

•  2  Ml  102  Support  Equipment  Trailers 

•  4  Remote  Sensor  Stations  (RSS) 

•  50  BAIS  Unattended  Ground  Sensors  (UGS) 

•  2  TAGS  Unmanned  Ground  Vehicles  (UGV) 

Remote  Sensor  Stations  are  emplaced  around  the 
perimeter  of  the  site  to  provide  wide-area  detection  and 
assessment.  Unattended  ground  sensors  are  emplaced 
along  likely  avenues  of  approach  such  as  roads  and 
wadis.  Multiple  UGVs  patrol  the  interior  of  the  site  as 
well  as  the  perimeter  to  fill  in  gaps  in  the  fixed  sensor 
coverage  using  randomized  patrol  patterns.  If  an 
intruder  is  detected,  the  closest  UGV  will  automatically 
be  cued  to  assess  this  potential  threat.  This  system  is 
controlled  using  JBC2S  which  is  hosted  in  a  HMMWV- 
shelter  based  command-and-control  station  [2]. 

3.  COMMAND  AND  CONTROL  ARCHITECTURE 
3.1  MRHA,  MOCU,  and  JBC2S 

The  Multiple  Resource  Host  Architecture  (MRHA)  was  developed  by  SSC  San  Diego  as  the  command-and-control 
system  for  the  Army’s  Mobile  Detection  Assessment  Response  System  (MDARS)  program.  MDARS  is  a  fixed-site 
robotic  security  system  that  consists  of  multiple  semi-autonomous  unmanned  ground  vehicles  (UGVs)  performing 
automated  patrols,  as  well  as  intrusion  sensors  and  active  barriers.  The  UGVs  can  automatically  detect  and  track 
intruders  and  perform  inventory  assessment  of  items  within  buildings  or  bunkers  using  RFID  tags.  The  MDARS 
program  is  currently  undergoing  extensive  testing  at  Hawthorne  Army  Depot  and  is  expected  to  enter  limited  production 
in  early  FY-07. 


Figure  1 :  Conceptual  deployment  of  the  FIRRE  system. 


SPIE  Unmanned  Systems  Technology  VIII ,  Orlando,  FL,  17-20  April,  2006 


The  Multiple-robot  Operator  Control  Unit  (MOCU)  [1]  was  developed  as  a  tactical  operator  control  unit  for  a  small 
man-portable  UGV  called  the  URBOT.  It  has  since  been  modified  to  control  the  SPARTAN  unmanned  surface  vehicle 
(USV)  as  well  as  the  iRobot  Packbot,  and  a  modified  Rotomotion  unmanned  aerial  vehicle  (UAV).  MOCU  differs  from 
the  MRHA  in  a  number  of  important  areas.  First,  MOCU  is  designed  from  the  ground  up  to  be  modular  and  scalable.  It 
can  be  run  on  an  embedded  handheld  or  high-end  desktop  computer.  MOCU  is  designed  to  allow  for  plug-and-play 
modules  that  support  new  C2  protocols,  video  CODECs,  mapping  engines,  and  other  components  to  be  added  without 
modifying  the  core  software.  MOCU  is  protocol,  video,  and  map  agnostic,  which  allows  it  to  grow  and  adapt  to  support 
new  platforms  using  whatever  the  interface  de  jour  may  be. 

The  MRHA,  on  the  other  hand,  was  developed  using  the  Ada  programming  language  and  has  become  increasingly 
difficult  to  maintain.  Additionally,  as  MDARS  nears  production,  it  has  become  difficult  to  add  new  features  since  the 
software  has  already  undergone  formal  testing.  Even  though  the  MRHA  was  designed  for  a  very  similar  mission  to 
FIRRE,  it  was  prudent  to  move  to  the  newer  MOCU  framework  to  allow  the  use  of  the  latest  software  tools  and  libraries, 
while  still  maintaining  backward  compatibility  by  implementing  an  MRHA  IDD  command-and-control  protocol  module. 
By  adding  the  MRHA  functionality  such  as  automated  path  planning  and  resource  scheduling  and  scripting  to  MOCU,  a 
single  software  application  could  be  created  that  would  consolidate  the  code  base  while  leveraging  over  10  years  of 
unmanned  systems  command  and  control  software  experience. 

The  MRHA  uses  proprietary  vector  graphics  to  depict  the  location  of  robots, 
sensors,  roads,  and  bunkers.  MOCU  features  much  more  advanced  2-D  vector 
and  raster  graphics  using  map  modules.  There  are  currently  map  modules  that 
support  GeoTIFFs,  World  Vector  Shoreline  (WVS),  Digital  Nautical  Charts 
using  the  COmmon  GEospatial  Navigation  Toolkit  (COGENT),  and  the 
Commercial  Joint  Mapping  Toolkit  (C/JMTK).  What  it  is  needed,  however,  is 
a  3-D  mapping  engine  that  will  allow  for  seamless  worldwide  coverage,  take 
advantage  of  modern  graphics  hardware,  and  provide  the  operator  with  better 
situational  awareness.  JBC2S  is  a  fusion  of  the  framework  of  MOCU,  the 
functionality  of  the  MRHA,  and  cutting  edge  2-D  and  3-D  visualization 
technology  (Figure  2). 

3.2  Communications 

The  requirements  of  FIRRE’ s  mission  dictated  the  use  of  high  power,  long  rang 
standard  802.11  wireless  networks  that  normally  used  for  robotic  applications.  Typically,  when  a  TCP/IP  network  is 
used,  both  command  and  control  and  video  signals  are  sent  over  the  same  link;  however,  there  are  currently  very  few 
TCP/IP  radios  capable  of  communicating  in  a  mobile  environment  with  bandwidth  sufficient  for  good  quality  video  and 
5+  KM  range.  The  few  radios  that  do  exist,  such  as  the  AN/VRC-99 ,  are  prohibitively  expensive  and  most  have 
embedded  COMSEC  encryption  that  makes  them  problematic  for  unmanned  systems.  FIRRE  uses  two  separate  radio 
links  that  provide  the  necessary  performance  while  staying  within  budget. 

Intuicom  Military  Navigator  II  (MilNavII)  UHF  transceivers  are  used  for  bi-directional  command  and  control  with  a 
maximum  throughput  of  128kbps  (full-duplex),  4W  output,  and  a  stated  60+  mile  range  (LOS).  The  MilNavII  can  be 
configured  in  point-to-point,  point-to-multipoint,  and  repeater  modes  and  also  has  a  built-in  WAAS  capable  GPS.  The 
MilNavII  radio  provides  three  virtual  RS-232  serial  channels  between  two  radios  in  point-to-point  mode.  The  first 
channel  is  used  for  bi-directional  command  and  control  using  a  derivative  of  the  MRHA  protocol.  The  second  channel 
provides  one-way  differential  GPS  correction  messages  from  the  FIRRE  C2  Station  to  the  UGV.  The  third  channel  can 
be  used  as  a  remote  terminal  into  the  FIRRE  UGV  to  allow  for  remote  debugging. 

DTC  Palladium  COFDM  transmitters  and  receivers  are  used  to  send  a  single  channel  of  high  quality  NTSC  video  to  the 
C2  Station.  To  achieve  the  desired  range,  a  12W  external  amplifier  was  added,  and  for  non-mobile  applications,  a  25°  15 
dB  directional  antenna  was  also  employed.  The  receiver  uses  two  omni-directional  antennas  in  a  spatial  diversity 
configuration. 


Figure  2:  JBC2S  architecture. 


communications  equipment  rather  than 
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Both  of  these  radio  links  are  used  in  point-to-point  mode.  The  current  limit  based  on  rack  space  in  the  C2  Station  is  6 
resources  (any  combination  of  FIRRE  UGVs  or  RSS  towers).  Support  for  additional  resources  can  be  provided  by 
connecting  external  radios  via  ethemet  or  adding  connectors  to  the  egress  panels  on  the  back  of  C2  Station. 

3.3  Protocol  Modules 

One  of  the  more  common  protocols  for  controlling  unmanned  vehicles  is  the  Joint  Architecture  for  Unmanned  Systems 
(JAUS)  which  provides  a  common  transport  layer  and  message  set  for  unmanned  vehicles  and  sensors.  This  protocol  is 
mandated  for  all  unmanned  systems  developed  for  the  Future  Combat  Systems  (FCS)  program  and  the  OSD  Joint 
Robotics  Program.  Though  JAUS  has  matured  significantly  over  the  last  few  years,  it  still  lacks  many  of  the  features 
required  for  the  FIRRE  mission.  JAUS  has  standardized  messages  for  controlling  core  robot  functions  such  as 
teleoperation  and  waypoint  navigation;  however  it  currently  lacks  a  standardized  way  of  adding  payloads,  such  as 
unattended  ground  sensors  and  ground  surveillance  radars  (though  work  is  under  way  in  this  area  by  the  JAUS  working 
group).  Typically,  developers  are  required  to  implement  “user-defined”  JAUS  messages  (JAUS  header  with  user-defined 
fields)  to  make  up  for  gaps  in  the  JAUS  standard.  Due  to  the  aggressive  nature  of  the  FIRRE  schedule,  it  was  determined 
that  the  MRHA  IDD  provided  a  lower  technical  risk.  The  transition  to  JAUS  will  be  undertaken  in  the  next  development 
spiral  when  the  standard  has  reached  a  higher  level  of  maturity. 

In  2001,  the  MRHA  protocol  was  extended  to  control  the  URBOT  UGV.  The  MRHA  software  developed  for  MDARS 
requires  a  static  list  of  all  the  resources  in  the  system.  For  the  URBOT  project,  an  extension  of  the  MRHA  protocol  was 
created  called  Small  Robot  Technology  (SMART)  that  provided  a  mechanism  for  dynamic  configuration.  Instead  of 
extending  the  existing  MRHA  software,  the  Multi-robot  Operator  Control  Unit  (MOCU)  software  was  developed.  This 
included  the  SMART  software  library  that  was  used  both  inside  MOCU  and  onboard  the  URBOT  and  to  handle  resource 
discovery  and  message  transport  and  parsing. 

Support  for  the  iRobot  Aware  and  JAUS  protocols  was  later  added  to  MOCU,  prompting  the  development  of  protocol 
modules.  At  runtime,  MOCU  scans  the  current  directory  for  DLLs  that  support  the  common  protocol  module  interface. 
MOCU  then  loads  these  DLLs  and  uses  them  to  translate  protocol  specific  commands  and  data-structures  to  a  common 
interface.  This  approach  allows  the  MOCU  core  and  user  interfaces  to  treat  all  resources  the  same  regardless  of  their 
native  protocol,  and  third-party  protocol  modules  to  be  added  without  having  to  re-compile  the  core  MOCU  software. 

For  FIRRE,  a  backwards-compatible  SMART/MRHA  protocol  module  was  developed  that  combined  the  transport  and 
message  parsing  of  the  SMART  library  with  the  features  of  the  legacy  MRHA  software,  and  the  new  features  required 
under  FIRRE  such  as  unattended  ground  sensors  and  ground  surveillance  radars  payloads.  When  the  SMART/MRHA 
protocol  module  was  mature  enough,  all  direct  references  to  SMART  were  removed  inside  of  MOCU,  and  the 
conversion  to  true  protocol  independence  was  completed.  JBC2S  makes  use  of  these  latest  additions  to  the  MOCU 
framework. 

3.4  C2  Link  Modules 

One  of  the  recent  additions  to  JBC2S  is  the  C2  Link  module.  This  interface  allows  new  modules  to  be  written  to  connect 
with  other  military  C2  systems  such  as  Composeable  Force  Net  (CFn),  Enhanced  Tactical  Automated  Security  System 
(eTASS),  Global  Command  and  Control  System  Maritime  (GCCS-M)  or  industry  standards  such  as  NMEA.  This  is 
JBC2S’s  most  flexible  interface  and  allows  for  publishing  and  subscribing  to  manned  and  unmanned  vehicle  locations, 
routes,  geometry,  and  tracks  at  varying  refresh  rates. 

In  the  summer  of  2006,  FIRRE  will  demonstrate  integration  with  the  U.S.  Army’s  C-RAM  program  using  the  eTASS 
XML  protocol  developed  originally  by  the  U.S.  Air  Force.  C-RAM  consists  of  a  system  of  overlapping,  networked  fire- 
finder  radars  that  are  capable  of  detecting  and  tracking  rocket,  mortar,  and  artillery  launches,  and  provide  warning  to  the 
affected  areas  of  a  forward  operating  base  (FOB).  This  integration  will  allow  the  C-RAM  eTASS  system  to  see  the 
location  of  FIRRE  UGVs,  UGSs,  RSS  towers,  and  intruders,  and  provide  high  level  control  and  queuing.  This  will  also 
allow  JBC2S  to  see  the  point  of  origin  and  impact  of  any  rocket,  artillery,  or  mortar  launches  in  the  immediate  area,  and 
the  locations  of  friendly  or  hostile  units  via  eTASS’s  interface  with  other  U.S.  Army  C2  systems. 
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3.5  Map  Modules 

The  look  and  feel  of  JBC2S  is  much  improved  over  the  MRHA  through  the  display  of  raster  graphics  data  in  addition  to 
vector  graphics  data.  The  use  of  raster  images  reveals  much  more  detail  about  the  environment  and  presents  a  modem, 
state-of-the-art  user  interface.  Written  to  be  modular  and  flexible,  JBC2S  defines  a  common  mapping  application 
interface. 


One  of  the  most  common  DoD  mapping  packages  is  the  suite  of  ESRI  products  included  in  the  Commercial  Joint 
Mapping  Toolkit  (C/JMTK)  program.  The  primary  utilities  of  C/JMTK  are  ArcGIS  Desktop  and  ArcGIS  Engine 
Developer’s  Kit  and  Runtime  (Figure  3).  They  natively  support  a  broad  range  of  geospatial  data  sources,  including 
GeoTIFF,  ADRG,  Compressed  ADRG  (CADRG),  Controlled  Image  Base  (CIB),  and  WVS.  These  data  sources  can  be 
seamlessly  tiled  together  in  either  2-D  or  3-D  viewing  modes.  The  suite  also  provides  many  tools  for  analyzing 
geospatial  data  and  converting  from  one  format  to  another.  A  map  module  was  written  to  embed  this  toolkit  in  JBC2S 
using  the  ArcGIS  Engine  Developer’s  Kit;  however,  some  serious  issues  were  encountered  that  have  temporarily  halted 
development.  One  of  these  issues  is  the  incompatibility  of  the  JBC2S  architecture  with  the  ArcGIS  Engine  architecture. 
In  the  JBC2S  architecture,  the  core  code  defines  how  the  application  behaves  and  dictates  how  modules  are  intended  to 
capture  messages  and  events,  and  call  back  to  the  core  code  through  callback  functions.  The  ArcGIS  Engine  architecture 
is  designed  to  support  cartographical  applications  and  is  intended  to  be  the  core  of  the  application  that  embeds  the 
toolkit.  The  toolkit  comes  with  its  own  toolbar,  ArcMap  (2-D),  ArcGlobe  (3-D),  and  ArcScene  (3-D)  components  that 
work  with  each  other.  When  integrated  into  JBC2S,  these  components  are  used  individually  and  significant  overhead 
code  is  needed  to  resolve  the  architecture  incompatibilities.  A  second  issue  is  the  lack  of  library  source  code  with  the 
API  that  makes  crashes  in  the  library  difficult  to  analyze  and  debug.  Perhaps  the  most  serious  problem  is  that  the 
recommended  approach  to  drawing  dynamic  lines  and  symbols  on  the  map  results  in  slow,  flashing  graphics.  Ultimately, 
it  was  the  slow  performance  of  the  toolkit  embedded  in  JBC2S  that  halted  development.  Efforts  continue  for  the 
integration  of  the  toolkit  in  other  ways.  For  example,  the  ArcGIS  Desktop  application  is  being  used  to  convert  and 
combine  different  map  formats  to  create  maps  for  use  by  other  JBC2S  map  modules. 

As  an  alternative  to  C/JMTK,  the  popular  and  freely  available  Google  Earth  (formerly  known  as  Keyhole)  is  being 
evaluated.  Integrating  Google  Earth  into  JBC2S  creates  it  own  set  of  complications  that  are  almost  opposite  of  those 
encountered  with  C/JMTK.  Through  its  XML-based  API,  Google  Earth  excels  at  drawing  dynamic  symbols  and  graphics 
on  top  of  the  map;  however,  it  is  not  designed  to  be  embedded  inside  of  other  applications,  and  the  API  is  essentially 
making  it  difficult  to  integrate  into  JBC2S.  Techniques  such  as  window  message  hooking  and  other  advanced  windows 
“hacks”  will  need  to  be  employed,  which  is  highly  undesirable.  Another  issue  is  the  reliance  on  internet  based  data, 
which  is  almost  never  available  in  military  command  and  control  systems.  This  can  likely  be  overcome  by  using  higher 
end  products  such  as  the  Fusion  Server  and  Enterprise  Client.  Efforts  are  on-going  to  integrate  Google  Earth  into  JBC2S 
(Figure  4). 


Figure  3:  C/JMTK  ArcGlobe. 


Figure  4:  Google  Earth  inside  MOCU. 
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Currently,  JBC2S  primarily  uses  map  modules  that  are  developed  in-house,  which  handle  2-D  display  of  maps  in  raster 
and  vector  formats.  This  approach  supports  a  limited  set  of  popular  data  formats  and  is  extended  as  needed  to  support 
new  data  formats.  These  map  modules  use  efficient  techniques  that  allow  for  smooth  graphic  transitions  during  zoom 
in/out  and  panning,  and  keep  up  with  real-time  events  common  to  the  robotics  environment;  Valuable  development  time, 
however,  is  being  consumed  to  make  up  for  the  lack  of  a  good  commercial  package  that  meets  these  needs. 

3.6  Control  Methodology 

In  order  to  simplify  the  user  interface,  JBC2S  operates  under  a  very  simple  rule  set.  The  system  is  either  in  Monitor 
Mode,  in  which  the  operator  observes  and  monitors  the  status  of  the  unmanned  vehicles  and  sensors  (known  collectively 
as  resources),  or  the  operator  is  in  Direct  Control  of  a  single  resource.  For  example,  a  resource  may  have  eight  cameras, 
two  radars,  and  four  lights,  but  only  a  single  camera,  radar,  and  light  is  controllable  at  any  given  time.  Multiple  cameras 
can  be  viewed  simultaneously,  but  the  operator  cannot  pan  two  of  them  at  the  same  time.  A  joystick  button  or  dialog 
button  can  be  configured  to  cycle  between  the  various  payloads.  This  paradigm  reduces  the  complexity  of  the  software 
and  simplifies  the  user  interface  presented. 

One  could  argue  that  it  would  be  useful  to  allow  control  of  multiple  unmanned  vehicles  simultaneously.  Many  modem 
real-time  strategy  video  games  allow  the  user  to  drag  a  box  around  a  group  of  units  and  send  them  to  a  location  on  the 
map  or  select  an  enemy  unit  to  engage;  however,  current  unmanned  vehicle  technology  does  not  possess  this  level  of 
autonomy.  As  the  autonomy  of  unmanned  vehicles  increases,  the  methodology  used  in  unmanned  vehicle  control 
software  will  need  to  continually  evolve. 


4.  UGV  INTEGRATION 


4.1  Vehicle  Status 

The  FIRRE  UGV,  developed  by  Northmp 
Gmmman/Remotec,  is  a  highly  mobile  tracked 
vehicle  capable  of  off-road  operation  (Figure  5). 

The  UGV  has  an  integrated  differential  GPS 
navigation  system  that  allows  for  high  accuracy 
waypoint  navigation  and  an  obstacle  detection 
system  consisting  of  a  SICK  LIDAR  mounted  on 
the  front  of  the  UGV  and  six  MA-Com  radars 
mounted  all  around  the  vehicle  to  provide  360- 
degree  coverage.  This  allows  the  vehicle  to 
automatically  stop  for  obstacles  in  its  path  during 
both  waypoint  navigation  and  manual 
teleoperation.  The  UGV  has  eight  cameras:  a 
front  color  driving  camera,  a  rear  color  driving 
camera,  four  wide-angle  black  and  white 
cameras,  and  the  SeaFLIR  stabilized  imager  with 
a  combination  FLIR  and  daylight  camera.  The 
vehicle  also  has  a  speaker  and  microphone  to 
allow  the  operator  to  interrogate  an  intruder.  To 
provide  the  ability  to  detect  personnel  and  vehicles,  the  UGV  is  equipped  with  an  AN/PPS-5D  ground  surveillance  radar. 
The  AN/PPS-5D  can  only  be  used  when  the  vehicle  is  stationary,  so  it  is  automatically  lowered  into  a  protective  cradle 
before  the  UGV  is  allowed  to  move.  Under  normal  operating  conditions,  the  UGV  will  be  automatically  dispatched 
according  to  a  schedule  established  by  the  company  commander.  The  UGVs  will  be  put  on  patrol,  sent  to  pre¬ 
programmed  points  of  interest,  and  commanded  to  perform  security  detection  scans  of  areas  of  interest.  A  variety  of 
actions  can  be  performed  along  paths  as  the  UGV  moves  between  points  of  interest  such  as  camera  movement,  intruder 
detection  scanning,  and  pre-recorded  audio  playback.  If  the  UGV  detects  a  potential  target  when  performing  a  security 
scan,  the  operator  will  be  automatically  notified,  wherein  the  operator  will  be  able  to  assess  the  nature  of  the  target  by:  1) 
manually  aiming  the  radar  at  the  potential  target  to  collect  additional  contact  data;  2)  listening  to  audio  from  the  radar,; 
and  3)  by  visual  means  using  the  SeaFLIR. 


Figure  5:  FIRRE  UGV. 
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The  operator  can  stop  the  UGV  when  it  is  patrolling  on  its  own  to  take  manual  control.  The  UGV  will  operate  in  a  semi- 
autonomous  mode  when  sent  to  a  point  of  interest  by  the  operator.  If  the  UGV  senses  an  obstacle  in  its  path,  it  will  stop 
and  request  assistance  from  the  operator  before  proceeding.  At  this  point  in  development,  the  UGV  does  not  attempt  to 
go  around  an  obstacle  on  its  own.  The  operator  has  to  manually  drive  the  UGV  around  the  obstacle,  and  then  resume  the 
UGV  on  its  path.  When  the  UGV  moves  near  or  through  areas  such  as  intersections,  cross  walks,  railroad  tracks,  or  other 
potentially  dangerous  areas  (from  a  personnel  safety  perspective),  the  UGV  may  ask  the  operator  for  clearance  before 
proceeding  through  the  area. 

The  operator  can  listen  to  audio  from  the  UGV  and  generate  pre-programmed  sounds  at  the  UGV,  as  well  as  speak 
through  the  UGV  to  personnel  near  the  vehicle.  The  operator  can  manually  operate  the  GSR  when  the  UGV  is  stopped. 
The  GSR  is  stowed  in  a  safe  position  while  the  UGV  is  in  motion.  The  operator  can  manually  operate  the  SeaFLIR  at  all 
times  when  the  UGV  is  powered  on. 

If  the  UGV  senses  that  it  is  low  on  fuel,  it  will  be  automatically  sent  to  a  predefined  re-fueling  location  and 
automatically  powered  down.  If  a  potential  target  is  detected  by  a  Remote  Sensor  Station  (either  the  ground  surveillance 
radar  or  the  unattended  ground  sensors),  the  operator  is  automatically  notified  and  a  UGV  is  automatically  dispatched  to 
a  point  near  the  detection  for  further  assessment.  More  than  one  UGV  can  be  operational  at  a  time. 


Figure  6:  FIRRE  UGV  control  in  JBC2S. 

The  UGV  provides  a  wide  range  of  telemetry  data  back  to  JBC2S  via  the  MRHA  IDD  protocol.  The  most  important 
message  in  the  MRHA  IDD  is  the  Platform  Get  Status  that  is  sent  to  resources  several  times  a  second.  Resources  must 
send  back  a  response  message  that  contains  their  location,  heading,  operational  mode,  and  other  platform-specific 
information.  The  UGV  provides  telemetry  data  such  as  engine  speed,  engine  temperature,  hydraulic  pressure,  hydraulic 
temperature,  track  speed,  fuel  level,  battery  voltage,  and  obstacle  detection  data  (Figure  6).  It  also  provides  the  pan/tilt 
positions  of  the  SeaFLIR  imager  and  the  AN/PPS-5D  radar.  JBC2S  uses  pan/tilt  information  to  display  coverage  areas 
for  these  sensors  on  the  map.  The  Platform  Get  Status  response  includes  a  number  of  flags  such  as  GPS  failure, 
emergency  halt,  low-battery  warning,  tamper  alarm,  and  diagnostic  failure.  If  the  diagnostic  failure  flag  is  set,  JBC2S 
queries  the  UGV  for  a  detailed  list  of  failures.  The  resource  responds  with  a  list  of  subsystems  that  have  failed.  The 
subsystems  are  identified  by  numbers  that  correspond  to  entries  in  a  JBC2S  configuration  file.  This  file  maps  a 
subsystem  number  to  a  textual  description,  which  provides  a  generic  mechanism  for  reporting  platform/manufacturer- 
specific  failures  to  the  operator. 
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4.2  Vehicle  Control 

In  JBC2S,  the  control  of  a  robot  is  broken  into  five  categories  based  on  the  robot’s  level  of  autonomy:  teleoperation, 
vector  driving,  waypoint  navigation,  static  path  planning,  and  dynamic  path  planning.  The  FIRRE  UGV  currently 
supports  all  of  these  levels  of  control  except  for  dynamic  path  planning. 

4.2.1  Teleoperation  and  Vector  Driving 

Teleoperation  is  actually  broken  into  two  types  that  are  usually  transparent  to  the  user.  In  manual  teleoperation,  the  user 
has  complete  control  over  the  throttle  and  steering  of  the  vehicle,  normally  via  a  joystick  or  handheld  controller.  In 
reflexive  teleoperation,  the  user  still  controls  the  throttle  and  steering,  but  the  robot’s  object  detection  and  avoidance 
system  attempts  to  keep  the  user  from  running  into  obstacles  [5].  If  a  robot  supports  reflexive  teleoperation,  then  it  is 
likely  that  this  will  be  the  only  type  of  teleoperation  available  to  the  user  for  safety  reasons.  To  provide  responsive 
teleoperation,  JBC2S  normally  sends  commands  from  the  joystick  at  a  20-Hz  rate.  Teleoperation  also  requires  low 
latency  video,  which  the  DTC  Palladium  video  transmitter  provides.  Typical  802.11 -based  systems,  which  use 
compressed  video,  may  have  a  second  or  more  of  latency  making  teleoperation  very  difficult  for  the  operator. 

Vector  driving,  used  mainly  with  US  Vs  or  UAVs  allows  the  operator  to  specify  the  desired  heading  and  speed  without 
having  to  provide  joystick  controls.  It  is  effectively  waypoint  navigation  with  a  single  waypoint  that  the  robot  can  never 
reach. 

4.2.2  Waypoint  Navigation  and  Path  Planning 

Waypoint  navigation  consists  of  the  user  drawing  a  series  of  waypoints  on  a  georeferenced  map,  or  manually  entering 
coordinates  using  a  keyboard  (Figure  7).  Each  waypoint  has  parameters  such  as  the  desired  speed,  lane  width  (how  far 
the  robot  can  deviate  from  the  centerline  to  circumnavigate  obstacles),  the  capture  radius  (how  close  the  robot  needs  to 
be  to  the  waypoint  to  consider  itself  at  the  waypoint),  and  actions  to  perform  at  the  waypoint  (halt,  slew  a  camera,  etc). 
Static  path  planning  consists  of  a  series  of  pre-surveyed  nodes  and  routes  between  the  nodes.  The  user  selects  a  node  and 
the  system  automatically  plans  a  path  from  the  unmanned  vehicle’s  current  position  to  the  selected  node  along  the  pre¬ 
surveyed  routes  (Figure  8).  Dynamic  path  planning  is  where  the  operator  selects  a  goal  point  and  the  robot  plans  the  best 
route  to  reach  that  point.  This  assumes  a  very  high  level  of  autonomy  on  the  part  of  the  unmanned  vehicle.  The  MRHA 
IDD  does  not  define  a  path  language  that  all  resources  are  required  to  use.  It  instead  provides  a  generic  download 
mechanism  that  allows  robot- specific  path  programs  to  be  downloaded  to  a  resource.  For  FIRRE ’s  UGV,  a  path 
language  was  developed  that  closely  matches  the  JAUS  waypoint  message  while  adding  additional  capabilities.  The 
overall  structure  of  the  language  is  very  simple  (Figure  9). 


Figure  7:  JBC2S  manual  waypoint  navigation. 


Figure  8:  JBC2S  static  path  planning. 


SPIE  Unmanned  Systems  Technology  VIII ,  Orlando,  FL,  17-20  April,  2006 


Field  # 

Nil  me 

Type 

Units 

Interpret  ill  inn 

1 

Number  of 
Waypoints 

Unsigned 

Short 

N/A 

Number  of  waypoints  in  this  path  (n-1) 

2 

Waypoint  0 

Waypoinl 

Structure 

N/A 

Waypoint  0  Data  Structure 

3 

Waypoint  l 

Waypoint 

Structure 

N/A 

Waypoint  1  Data  Structure 

n 

Waypoint  n 

Waypoint 

Structure 

N/A 

Waypoint  n  Data  Structure 

Figure  9:  UGV  waypoint  language. 


Each  waypoint  structure  (Figure  10)  contains  the  location  of  the  waypoint  in  geodetic  coordinates,  roll,  pitch,  and  yaw  at 
this  waypoint,  the  desired  speed  along  the  path  to  this  waypoint,  and  other  tolerances.  It  also  contains  lane  width  and 
height  fields  that  specify  how  far  the  vehicle  can  deviate  from  the  centerline  to  circumnavigate  around  obstacles.  The  last 
field  is  the  action  script  which  is  the  most  powerful  part  of  FIRRE’s  UGV  path  language  (Figure  11). 


Field  # 

Name 

Description 

i 

Presence  Vector 

Flags  to  indicate  the  presence  of  the  optional 
fields  in  this  structure 

2 

Waypoint  Number 

Waypoint  Identifier 

3 

Latitude 

Latitude  of  Waypoint  Goal 

4 

Longitude 

Longitude  of  Waypoint  Goal 

5 

Elevation 

Elevation  of  Waypoint  Goal 

6 

4>  (Roll) 

Desired  Roll  at  Waypoint  Goal 

7 

0  (Pitch) 

Desired  Pitch  at  Waypoint  Goal 

8 

\|/  (Y  aw) 

Desired  Yaw  at  Waypoint  Goal 

9 

Speed 

Desired  Speed  between  Waypoints 

10 

Capture  Radius 

Effective  Size  of  the  Waypoint  Goal 

11 

Roll  Tolerance  at  Goal 

Roll  Accuracy  Desired  at  Waypoint  Goal 

12 

Pitch  Tolerance  at  Goal 

Pitch  Accuracy  Desired  at  Waypoint  Goal 

13 

Yaw  Tolerance  at  Goal 

Yaw  Accuracy  Desired  at  Waypoint  Goal 

14 

Lane  Width 

Deviation  allowed  in  the  horizontal  plane 
along  this  path  segment 

15 

Lane  Height 

Deviation  allowed  in  the  vertical  plane  along 
this  path  segment 

16 

Action  Script 

Scripted  actions  to  perform  once  platform  has 
reached  waypoint  goal. 

Function  Name 

Description 

PAUSE 

Pause  platform  (blocking) 

HALT 

Halt  the  platform 

OFFLINE 

Put  platform  offline 

SENTRY 

Start  Stop  Sentry*  Mode 

CAMERASCAN 

Perform  area  scan  with  camera 

CAMERAMOVE 

Move  camera  to  specified  pose 

CAMERASELECT 

Select  a  camera  video  stream  for  transmission 

SOUNDHORN 

Sound  the  horn 

PLAYSOUND 

Playr  a  sound  on  the  platform 

LIGHTS 

Turn  on  off  the  platform's  lights 

WAITCLEARANCE 

Wait  for  operator  clearance  to  proceed 

RESTART 

Restart  Path  Program  Execution 

Figure  10:  UGV  waypoint  structure.  Figure  11:  UGV  action  script  functions. 

Action  scripts  are  a  series  of  ASCII  text  commands  that  allow  for  scripted  actions  when  the  UGV  reaches  a  waypoint. 
The  syntax  of  a  script  is  modeled  after  C/C++  and  consists  of  functions  with  parameters  and  terminating  semi  colons. 
The  available  functions  consist  of  mode  changes,  camera  movement,  playing  of  sounds,  and  controlling  lights.  The 
WAITCLEARANCE  function  forces  the  UGV  to  request  clearance  from  the  operator  before  proceeding  with  the  script. 
This  can  be  used  at  intersections  to  allow  the  operator  to  verify  that  it  is  safe  to  proceed.  The  RESTART  function  causes 
the  UGV  to  restart  this  path  program  from  the  beginning  to  allow  for  looping  patrols.  Here  is  an  example  of  an  action 
script: 


SENTRY (ON) ; 

CAMERASCAN (ON,  1,  90,  180)  ; 
PAUSE (120) ; 

SENTRY (OFF) ; 
WAITCLEARANCE () ; 


//  Enter  Sentry  mode 
//  Camera  area  scan 
//  Pause  for  120  seconds 
//  Return  to  Idle  mode 
//  Wait  for  operator  clearance 


4.2.3  Automated  Path  Planning 

Like  the  legacy  MRHA  software  developed  for  MDARS,  JBC2S  supports  automated  path  planning  but  uses  a  more 
flexible  XML-based  path  database.  This  database  consists  of  pre-defmed  nodes  and  interconnecting  routes.  When  the 
operator  selects  a  destination  node  for  a  robot,  a  recursive  depth-first  search  algorithm  is  used  to  find  the  shortest  route 
using  pre-programmed  routes.  For  fixed  installations,  this  capability  is  required  to  allow  for  automated  patrols  of 
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perimeter  roads,  bunkers,  and  facilities.  The  FIRRE  combat  developers  have  many  times  expressed  an  interest  in  being 
able  to  plan  routes  off-road  to  allow  for  quicker  and  more  dynamic  reactions  to  events,  and  to  take  full  advantage  of  the 
UGV’s  mobility.  Currently,  off-road  path  planning  is  possible,  but  only  along  known  surveyed  routes.  The  next  step  is  to 
allow  the  operator  to  plan  routes  through  unsurveyed  areas  using  a  combination  of  terrain  data  and  obstacle-detection 
sensors  and  avoidance  algorithms,  but  this  is  beyond  the  scope  of  FIRRE’ s  initial  spiral  development. 

5.  PAYLOAD  INTEGRATION 


5.1  Cameras 

FIRRE  employs  several  cameras,  each  with  different  capabilities  and  features.  FIRRE’ s  UGV  has  a  number  of  fixed 
cameras  for  situational  awareness  around  the  vehicle  as  well  as  the  SeaFLIR  II  (Figure  13),  which  is  a  stabilized  FLIR 
and  daylight  pan/tilt/zoom  camera  with  an  integrated  visual  tracker  and  laser  pointer.  FIRRE ’s  RSS  [3]  has  a  DI-5000 
FLIR  and  daylight  pan/tilt/zoom  camera  (Figure  14)  that  allows  for  blending  between  infrared  and  daylight  images 
(known  as  fading). 


Figure  13:  SeaFLIR  II  FLIR.  Figure  14:  DI-5000  FLIR.  Figure  15:  Slew-to-Cue  tool. 


If  the  video  is  available  in  digital  form  (e.g.  streaming  MPEG-4)  it  can  be  displayed  inside  JBC2S  either  in  a  fixed  or 
floating  video  window.  JBC2S  currently  supports  both  the  Video  Bridge  6000/8000  and  the  Axis  Video  Server  CODECs 
via  a  generic  DLL  interface,  allowing  future  CODECs  to  be  added  without  any  changes  to  the  core  JBC2S  software. 
JBC2S  allows  cameras  to  be  controlled  via  a  control  dialog,  a  joystick,  or  via  the  Slew-to-Cue  tool  (Figure  15).  The 
control  dialog  features  pan/tilt/zoom  controls  as  well  as  focus,  gain,  and  fader  controls.  Joystick  commands  are  user 
defined  and  can  be  easily  customized  for  different  joysticks  and  applications.  The  Slew-to-Cue  tool  allows  the  operator 
to  aim  a  camera  at  a  georeferenced  point  using  a  map.  Coverage  areas  of  cameras  can  also  be  displayed  on  the  map, 
allowing  the  user  to  better  visualize  how  the  video  relates  to  real  world  coordinates. 

5.2  Ground  Surveillance  Radar 

To  provide  long-range  intruder  detection,  AN/PPS-5D  ground  surveillance  radars  (GSR)  (Figure  16)  are  integrated  onto 
the  RSS  towers  and  the  UGV.  The  AN/PPS-5D  is  a  Doppler  radar  capable  of  detecting  personnel  and  vehicles  at  10-20 
KM;  however,  terrain  obstructions  can  significantly  decrease  the  performance.  The  AN/PPS-5D  can  be  manually  steered 
or  set  to  perform  an  area  scan  up  to  359  degrees  in  width.  The  AN/PPS-5D  is  normally  controlled  and  monitored  by  co¬ 
located  trained  personnel  and  was  not  designed  to  be  remotely  operated.  This  has  resulted  in  some  integration  challenges 
that  are  still  being  researched.  Perhaps  the  most  serious  issue  is  that  the  AN/PPS-5D ’s  pan  positioner  cannot  determine 
absolute  heading  and  initializes  to  0  degrees  heading  on  power-up.  A  proximity  sensor  system  has  been  developed  to 
allow  for  automated  calibration,  which  is  necessary  to  ensure  that  radar  data  can  accurately  be  displayed  on  a 
georeferenced  map  inside  of  JBC2S.  Another  issue  is  that  the  radar’s  tilt  is  not  remotely  controllable,  which  can  be 
problematic  in  anything  but  the  flattest  terrain. 
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The  radar  reports  contacts  as  uncorrelated  points  with  a  range,  bearing,  amplitude,  and  Doppler  velocity  (Figure  17).  The 
lack  of  an  integrated  tracker  greatly  increases  the  burden  on  the  operator.  The  radar  has  Doppler  audio  that  is  required  to 
accurately  determine  if  contacts  are  noise,  personnel,  or  vehicles.  More  development  is  needed  to  improve  the  utility  of 
this  radar  for  automated  fixed-site  security  applications  such  as  FIRRE. 


Figure  16:  AN/PPS-5D  Ground  Surveillance  Figure  17:  JBC2S  Controlling  PPS-5D. 


5.3  Unattended  Ground  Sensors 

The  Battlefield  Anti-Intrusion  System  (BAIS)  (Figure  18)  is  used  to  augment  the  wide-area  coverage  of  the  AN/PPS-5D 
radar.  These  combination  seismic  and  acoustic  sensors  allow  for  monitoring  likely  avenues  of  approach  such  as  roads, 
wadis,  heavy  vegetation,  etc,  that  don  not  lend  themselves  to  other  sensors.  The  BAIS  is  the  latest  generation  of  the 
Remote  Battlefield  Sensor  System  (REMBASS)  that  has  been  around  for  over  20  years.  The  BAIS  sensors  can  detect 
personnel  at  up  to  50  meters  and  vehicles  at  250-350  meters.  The  sensors  automatically  classify  detections  as  personnel, 
vehicle,  wheeled  vehicle,  tracked  vehicle,  or  unknown.  Messages  from  emplaced  sensors  are  received  using  a  handheld 
monitor  that  communicates  with  a  PC  using  an  RS-232  interface. 

For  FIRRE,  these  handheld  monitors  are  integrated  into  the  RSS  and  C2  Station  to  allow  BAIS  detection  and  status 
messages  to  be  fed  into  JBC2S.  The  locations  of  sensors  are  displayed  on  the  map  using  MIL-STD-2525B  symbols. 
When  a  sensor  reports  a  detection,  JBC2S  flashes  a  red  icon  on  top  of  the  sensor  symbol  indicating  the  type  of  event,  an 
audio  notification  is  played,  and  the  event  is  logged  for  later  review  and  analysis  (Figure  19). 


Figure  18:  Battlefield  Anti-Intrusion  System  (BAIS). 


Figure  19:  JBC2S  displaying  BAIS  event. 
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5.4  Lessons  Learned 

With  each  new  robot  or  payload  comes  its  own  set  of  challenges.  The  most  important  lesson  learned  during  payload 
integration  is  that  all  payloads  (cameras,  sensors,  radars,  weapons,  etc)  share  commonalities  that  need  to  be  exploited  to 
minimize  software  development  effort.  A  new  payload  architecture  for  JBC2S  is  being  developed  that  will  generalize 
both  the  interface  with  payloads  and  the  way  that  the  controls  for  payloads  are  presented  to  the  user. 

6.  FUTURE  EFFORTS 

In  the  near  term,  JBC2S  will  be  integrated  with  the  MDARS  platform  for  backwards  compatibility  as  well  as  to  provide 
an  alternative  vehicle  platform.  A  non-lethal  payload  utilizing  the  Long  Range  Acoustic  Device  (LRAD),  a  high-power 
direction  speaker  system,  is  being  developed  for  the  FIRRE  UGV  to  provide  a  response  capability.  A  software-based 
video  distribution  server  is  being  developed  to  provide  the  ability  to  stream  multiple  live  video  feeds  from  resources 
across  a  LAN  or  the  internet. 

In  the  next  spiral  of  development  for  FIRRE,  other  payloads  will  be  considered  for  integration  such  as  wide-area  infrared 
sensors  and  unattended  lethal/non-lethal  weapon  systems  such  as  the  Common  Remotely  Operated  Weapons  System 
(CROWS),  MATRIX,  and  the  Networked  Remotely  Operated  Weapons  System  (NROWS).  Additional  plans  include 
integration  of  FIRRE  with  a  multitude  of  other  unmanned  systems  including  USVs,  UAVs,  and  other  UGSs.  SSC  SD  has 
already  demonstrated  the  simultaneous  command-and-control  of  multiple  UGVs,  USVs,  and  UAVs  using  MOCU  [4]. 
FIRRE  will  push  the  readiness  level  of  the  unmanned  systems  and  integrate  control  of  these  systems  into  JBC2S. 
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